Generic maintenance activity scheduling

ABSTRACT

A system for configuring generic maintenance activity scheduling is provided. For example, user input may help define a maintenance process for a plurality of mobile drive units of the physical workspace. The maintenance process may be defined through a configuration of activity templates and input templates. Input may be received to configure maintenance activities and the system may automatically correlate failure rules with the activity template. The system may generate the configurable electronic instructions for the mobile drive units and transmit them with the failure rules, if generated, to one or more mobile drive units of the physical workspace. When the one or more mobile device units receive the configurable electronic instruction, the mobile drive units may operate in accordance with the configurable electronic instruction.

BACKGROUND

As electronic systems become more ubiquitous, technical issues arisewith maintaining these complex, electronic systems. For example, inmodern inventory systems such as those in mail order warehouses, supplychain distribution centers, airport luggage systems, and custom-ordermanufacturing facilities, the electronic systems that run these moderninventory systems face significant challenges in responding to requestsfor inventory items, especially when the systems are not functioningproperly. Thus, in many instances, the electronic systems may becomeinefficient when the electronics become out of date or are notfunctioning properly.

Several technical problems arise with these complex, electronic systems.For example, these systems may limit the ability of users to maintainmobile drive units in a physical warehouse and may delay the process formaintaining individual components of the mobile drive units, which isnot straightforward and often requires specialized knowledge.

As a sample illustration, a single user may be tasked with maintainingthese mobile drive units, even though other users with differentspecialties may not have access to maintaining these mobile drive units,despite their specialties. When the task of maintaining the mobile driveunits comprises replacing specialized hardware or upgrading othercomponents of the mobile drive units, the single user may be unable toprovide efficient maintenance, thus causing the mobile drive units to betaken offline for a longer period of time than needed. This in turndecreases the throughput of the overall system.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 illustrates an example architecture for providing genericmaintenance activity scheduling described herein that includes a backendcomputing device, management module, and/or a mobile drive unitconnected via one or more networks, according to at least one example;

FIG. 2 illustrates an example architecture of the backend computingdevice and schedule data store, according to at least one example;

FIG. 3 illustrates in greater detail components of an example managementmodule that may be utilized in particular embodiments of the inventorysystem as described herein, in accordance with at least one embodiment;

FIGS. 4A and 4B illustrate in greater detail an example mobile driveunit that may be utilized in particular embodiments of the inventorysystem as described herein, in accordance with at least one embodiment;

FIG. 5 illustrates a process flow of user interfaces provided by acomputing device, in accordance with at least one embodiment;

FIG. 6 illustrates an activity template submission workflow, inaccordance with at least one embodiment;

FIG. 7 illustrates an activity template update, in accordance with atleast one embodiment;

FIG. 8 illustrates a sample user interface for scheduling a reoccurringactivity, in accordance with at least one embodiment;

FIG. 9 illustrates an illustrative queued drive maintenance workflow, inaccordance with at least one embodiment;

FIG. 10 illustrates an example flow diagram for providing genericmaintenance activity scheduling described herein, according to at leastone example; and

FIG. 11 illustrates an environment in which various embodiments can beimplemented.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Embodiments of the present disclosure are directed to, among otherthings, a system for providing generic maintenance activity scheduling.For example, a computing device may present a user interface thatcomprises a plurality of fields for accepting user input. The user inputmay help define a maintenance process for a plurality of mobile driveunits of the physical workspace. In some examples, the maintenanceprocess may be defined through a configuration of one or more activitytemplates and input templates. The computing device may receive firstuser input associated with the activity template and, in some examples,automatically correlate failure rules with the activity template basedat least in part on the first user input. The computing device may alsoreceive second user input associated with the input template. The seconduser input may correspond with particular mobile drive units,configuration settings, firmware information (e.g., firmware version),component upgrade information, calibration settings, or otherinformation that may be used with the activity template to generateconfigurable electronic instructions. Once determined, the computingdevice may transmit a configurable electronic instruction and thefailure rules, if generated, to one or more mobile drive units of thephysical workspace. When the one or more mobile device units receive theconfigurable electronic instruction, the mobile drive units may operatein accordance with the configurable electronic instruction.

In an illustrative example, a server computer of the system provides auser interface with fields for the user to define a new maintenanceactivity template, input profile, view ongoing maintenance for themobile drive units, or schedule feature maintenance for the mobile driveunits. The user may select the option to generate a new maintenanceactivity template. In response, the system may display a user interfacefor accepting the definition and configurable settings of the activitytemplate. The user may define one or more activities for the mobiledrive unit. For example, the first activity may correspond withinstructing the mobile drive unit to drive to a first location, thesecond activity may correspond with instructing the mobile drive unit toreceive a firmware upgrade, and the third activity may correspond withinstructing the mobile drive unit to return to its original locationfrom the first location. These three activities may be associated withthe activity template. The server computer may also receive a name orother identifier for the new activity template and store the newactivity template in a data store.

The server computer may update the user interface to accept a new inputprofile through an input template. For example, continuing with thisillustration, the user may access the maintenance activity template thatit created and provide input for the created activity template. Theinput may correspond with particular mobile drive units that willreceive the firmware upgrade according to the activity template or otherinformation. The other information may comprise the version number ofthe firmware upgrade, an executable file associated with the firmwareupgrade, a device that may perform the firmware upgrade, or otherrelevant information. In some examples, the information may bepre-filtered so that the user is only able to select input that ispermissible by the system for the particular mobile drive unit oroperation(s). The server computer may also receive a name or otheridentifier for the new input template and store the new input templatein a data store.

Once the activity template and input template have been defined, theserver computer may determine configurable electronic instructions thatcorrespond with the identified input from the user. The computer maytransmit the configurable electronic instruction to an on premisecomputer or management module in the physical warehouse, which may inturn transmit the configurable electronic instructions to one or moremobile drive units that are affected by the configurable electronicinstructions from the server computer. In some examples, the computermay transmit the configurable electronic instruction directly to themobile drive unit.

In continuing with the illustrative example, a mobile drive unit mayreceive the configurable instructions from the on premise computer ormanagement module, or directly from the server computer via acommunication network. The mobile drive unit may perform the operationsaccording to the configurable electronic instruction. In some examples,the mobile drive unit may be operating in response to a differentinstruction when the configurable electronic instruction is received.The mobile drive unit may complete the current instruction and/orinitiate the received configurable electronic instruction according to aranking process of which instructions take precedence. The mobile driveunit, according to the input received from the user, may drive to thefirst location in the physical workspace, receive a firmware upgrade atthe first location, and once the firmware upgrade is complete, themobile drive unit may return to its original location to perform otheroperations (e.g., according to the three-step process defined in theactivity template, etc.).

Embodiments of the disclosure provides several technical advantages overprior systems. For example, prior systems may limit the ability of usersto generate configurable electronic instructions for mobile drive unitsin a physical warehouse. For example, in these prior systems, a singleuser may be tasked with providing instructions to mobile drive unit.Other users with different specialties in these prior systems may nothave access to providing instructions to the mobile drive units, despitetheir specialties. In the present system, by allowing the flexibility ofproviding a generic process for creating new configurable electronicinstructions for mobile drive units, the system is more efficient byreducing redundant development efforts and allowing more efficientmaintenance processes to be implemented. Additionally, the mobile driveunits may operate more effectively according to the specialistsproviding the configurable electronic instructions and generating newactivity and input templates for use.

FIG. 1 illustrates an example architecture for providing genericmaintenance activity scheduling described herein that includes a backendcomputing device, management module, and/or a mobile drive unitconnected via one or more networks, according to at least one example.In illustration 100, the system for providing generic maintenanceactivity scheduling may comprise a user 102 operating a user device 104,a backend computing device 106, a management module 109, a mobile driveunit 114, and one or more communication networks 108, 112, 116.

In illustration 100, one or more users 102 (i.e., web browser users) mayutilize user computing devices 104(1)-(N) (collectively, user devices104) to access an application (e.g., a web browser), via one or morenetworks. In some aspects, the application may be hosted, managed,and/or provided by a computing resources service or service provider,such as by utilizing one or more service provider computers and/or oneor more backend computing devices 106. The one or more backend computingdevices 106 may, in some examples, provide computing resources such as,but not limited to, client entities, low latency data storage, durabledata storage, data access, management, virtualization, cloud-basedsoftware solutions, electronic content performance management, etc. Theone or more backend computing devices 106 may also be operable toprovide web hosting, computer application development, and/orimplementation platforms, combinations of the foregoing, or the like tothe one or more users 102. The one or more backend computing devices106, in some examples, may help provide generic maintenance activityscheduling for user devices 104.

The application may allow the users 102 to interact with a serviceprovider computer, such as to access web content (e.g., web pages,music, video, etc.). The one or more backend computing devices 106,perhaps arranged in a cluster of servers or as a server farm, may hostthe application and/or cloud-based software services. Other serverarchitectures may also be used to host the application. The applicationmay be capable of handling requests from many users 102 and serving, inresponse, various item web pages. The application can provide any typeof website that supports user interaction, including social networkingsites, online retailers, informational sites, blog sites, search enginesites, news and entertainment sites, and so forth. As discussed above,the described techniques can similarly be implemented outside of theapplication, such as with other applications running on the user devices104.

The user devices 104 may be any type of computing device such as, butnot limited to, a mobile phone, a smart phone, a personal digitalassistant (PDA), a laptop computer, a desktop computer, a thin-clientdevice, a tablet PC, an electronic book (e-book) reader, etc. In someexamples, the user devices 104 may be in communication with the backendcomputing devices 106 via the networks 108, 112, 116, or via othernetwork connections. Additionally, the user devices 104 may be part ofthe distributed system managed by, controlled by, or otherwise part ofthe backend computing devices 106 (e.g., a console device integratedwith the backend computing devices 106).

In one illustrative configuration, the user devices 104 may include atleast one memory and one or more processing units (or processor(s)). Theprocessor(s) may be implemented as appropriate in hardware,computer-executable instructions, firmware, or combinations thereof.Computer-executable instruction or firmware implementations of theprocessor(s) may include computer-executable or machine-executableinstructions written in any suitable programming language to perform thevarious functions described. The user devices 104 may also includegeo-location devices (e.g., a global positioning system (GPS) device orthe like) for providing and/or recording geographic location informationassociated with the user devices 104.

The memory may store program instructions that are loadable andexecutable on the processor(s), as well as data generated during theexecution of these programs. Depending on the configuration and type ofuser devices 104, the memory may be volatile (such as random accessmemory (RAM)) and/or non-volatile (such as read-only memory (ROM), flashmemory, etc.). The user devices 104 may also include additionalremovable storage and/or non-removable storage including, but notlimited to, magnetic storage, optical disks, and/or tape storage. Thedisk drives and their associated computer-readable media may providenon-volatile storage of computer-readable instructions, data structures,program modules, and other data for the computing devices. In someimplementations, the memory may include multiple different types ofmemory, such as static random access memory (SRAM), dynamic randomaccess memory (DRAM), or ROM.

Turning to the contents of the memory of the user devices 104 in moredetail, the memory may include an operating system and one or moreapplication programs or services for implementing the features disclosedherein, such as via the browser application or dedicated applications(e.g., smart phone applications, tablet applications, etc.). The browserapplication may be configured to receive, store, and/or display awebsite or other interface for interacting with the backend computingdevices 106. Additionally, the memory may store access credentialsand/or other user information such as, but not limited to, user IDs,passwords, and/or other user information. In some examples, the userinformation may include information for authenticating an account accessrequest such as, but not limited to, a device ID, a cookie, an IPaddress, a location, or the like. In addition, the user information mayinclude a user 102 provided response to a security question or ageographic location obtained by the user devices 104.

The backend computing device 106 may provide an application programminginterface (API) or other user interface accessible by the user operatingthe user device 104. The backend computing device 106 may present theuser interface that comprises a plurality of fields for accepting inputfrom the user device via a first communication network. The user inputmay define a maintenance process for the mobile drive unit 114 of aphysical workspace. The user interface may comprise at least one fieldassociated with the user input for receiving configuration of anactivity template and an input template. Through this process, the userdevice 104 may be able to provide input to control one or moreoperations of the mobile drive unit 114 while the mobile drive unit 114maintains a default set of instructions for operation around thephysical workspace. The backend computing device 106 may receive theuser input via a first communication network and correlate the userinput with the activity template.

The management module 109 may be located within a physical workspace 118and also communicate with the mobile drive unit 114. For example,management module 109 may transmit an instruction to mobile drive unit114 to move to a first location to accept an item from a picking areaand drive to a second location where the item will be stored or stowed.In some examples, management module 109 may implement an executableinstruction (e.g., script, etc.) that provides one or more activities tomobile drive unit 114 with in the physical workspace 118. The executablefiles may be stored with a data store of executable files associatedwith the backend computing device 106 and/or management module 109. Insome examples, the instructions may be incorporated with andata-interchange format that does not correspond with an executable file(e.g., JSON or JavaScript Object Notation).

In some examples, the management module 109 may assign tasks tocomponents of inventory system and coordinate operation of the variouscomponents in completing the tasks. These tasks may relate not only tothe movement and processing of inventory items, but also to themanagement and maintenance of the components of inventory system. Forexample, management module 109 may assign portions of physical workspace118 as parking spaces for mobile drive units 114, the scheduled rechargeor replacement of mobile drive unit batteries, the storage of containerholders, or any other operations associated with the functionalitysupported by inventory system and its various components. Managementmodule 109 may select components of inventory system to perform thesetasks and communicate appropriate commands and/or data to the selectedcomponents to facilitate completion of these operations.

In a particular embodiment, mobile drive units 114 representindependent, self-powered devices configured to freely move aboutphysical workspace 118. Examples of such inventory systems are disclosedin U.S. Pat. No. 9,087,314, issued on Jul. 21, 2015, titled “SYSTEM ANDMETHOD FOR POSITIONING A MOBILE DRIVE UNIT”, and U.S. Pat. No.8,280,547, issued on Oct. 2, 2012, titled “METHOD AND SYSTEM FORTRANSPORTING INVENTORY ITEMS”, the entire disclosures of which areherein incorporated by reference. In alternative embodiments, mobiledrive units 114 represent elements of a tracked inventory systemconfigured to move container holders along tracks, rails, cables, cranesystem, or other guidance or support elements traversing physicalworkspace 118. The mobile drive unit 114 may also communicate withbackend computing device 106 or management module 109 via one or morenetworks. Mobile drive unit 114 may operate according to instructionsthat are stored locally at mobile drive unit 114 or remotely from one ormore computing devices. Additional details for each of these computingdevices are provided throughout the disclosure.

The management module 109 and the mobile drive unit 114 may operate in aphysical workspace 118. Mobile drive units 114 may transport containerholders between points within the physical workspace 118 in response tocommands communicated by management module 109. Each container holderstores one or more containers. Each container may store one or moretypes of inventory items. As a result, inventory system is capable ofmoving inventory items between locations within physical workspace 118to facilitate the entry, processing, and/or removal of inventory itemsfrom inventory system and the completion of other tasks involvinginventory items.

In some examples, the networks 108, 112, 116 may include any one or acombination of many different types of networks, such as cable networks,the Internet, wireless networks, cellular networks and other privateand/or public networks. While the illustrated example represents theusers 102 accessing the application over the networks 108, 112, 116, thedescribed techniques may equally apply in instances where the users 102interact with the backend computing devices 106 via the one or more userdevices 104 over a landline phone, via a kiosk, or in any other manner.It is also noted that the described techniques may apply in otherclient/server arrangements (e.g., set-top boxes, etc.), as well as innon-client/server arrangements (e.g., locally stored applications,etc.). As one example, particular embodiments of mobile drive unit 114may communicate with management module 109 and/or with one another using802.11, Bluetooth, or Infrared Data Association (IrDA) standards, or anyother appropriate wireless communication protocol.

The mobile drive units 114 may transport inventory items. Inventoryitems may represent any objects suitable for storage, retrieval, and/orprocessing in an automated inventory system. For the purposes of thisdescription, “inventory items” may represent any one or more objects ofa particular type that are stored in inventory system. During operation,mobile drive units 114 may retrieve container holders containing one ormore inventory items requested in an order to be packed for delivery toa customer or container holders carrying pallets containing aggregatedcollections of inventory items for shipment. Moreover, in particularembodiments of inventory system, boxes containing completed orders maythemselves represent inventory items.

In particular embodiments, inventory system may also include one or moreinventory stations. Inventory stations represent locations designatedfor the completion of particular tasks involving inventory items,including the performance of maintenance tasks determined by a user 102operating a user device 104 and received from a backend computing device106. Such tasks may also include the removal of inventory items and/orcontainers from container holders and/or container shuttles, theintroduction of inventory items and/or containers into container holdersand/or container shuttles, the counting of inventory items and/orcontainers in container holders and/or container shuttles, thedecomposition of inventory items (e.g. from pallet- or case-sized groupsto individual inventory items) into containers in container holdersand/or container shuttles, the consolidation of inventory items and/orcontainers between container holders and/or container shuttles, transferof inventory items and/or containers between container holders and/orcontainer shuttles, and/or the processing or handling of inventory itemsin any other suitable manner. In particular embodiments, inventorystations may represent the physical locations where a particular taskinvolving inventory items can be completed within physical workspace118. In alternative embodiments, inventory stations may represent boththe physical location and also any appropriate equipment for processingor handling inventory items, such as scanners for monitoring the flow ofinventory items in and out of inventory system, communication interfacesfor communicating with management module 109, and/or any other suitablecomponents. Inventory stations may be controlled, entirely or in part,by human operators or may be fully automated. Moreover, the human orautomated operators of inventory stations may be capable of performingcertain tasks to inventory items, such as packing, counting, ortransferring inventory items, as part of the operation of inventorysystem.

Physical workspace 118 represents an area associated with inventorysystem in which mobile drive units 114 can move and/or container holderscan be stored. This may also correspond with a physical workspacediscussed throughout the disclosure. For example, physical workspace 118may represent all or part of the floor of a mail-order warehouse inwhich inventory system operates. The physical workspace 118 may includea fixed, predetermined, and finite physical space, or, in particularembodiments, the physical workspace 118 may comprise a variabledimensions and/or an arbitrary geometry space for movement of the mobiledrive units 114. In some embodiments, the physical workspace 118 may beentirely enclosed in a building, or may also be located outdoors, withina vehicle (such as a cargo ship), located across more than one floor, orotherwise unconstrained by any fixed structure.

In operation, management module 109 selects appropriate components tocomplete particular tasks and transmits task assignments to the selectedcomponents to trigger completion of the relevant tasks. Each taskassignment defines one or more tasks to be completed by a particularcomponent. These tasks may relate to the retrieval, storage,replenishment, and counting of inventory items and/or the management ofmobile drive units 114, container holders, inventory stations and othercomponents of inventory system. Depending on the component and the taskto be completed, a particular task assignment may identify locations,components, and/or actions associated with the corresponding task and/orany other appropriate information to be used by the relevant componentin completing the assigned task.

In particular embodiments, management module 109 generates taskassignments based, in part, on inventory requests that management module109 receives from other components of inventory system and/or fromexternal components in communication with management module 109. Theseinventory requests identify particular operations to be completedinvolving inventory items stored or to be stored within inventory systemand may represent communication of any suitable form. For example, inparticular embodiments, an inventory request may represent a shippingorder specifying particular inventory items that have been purchased bya customer and that are to be retrieved from inventory system forshipment to the customer. Management module 109 may also generate taskassignments independently of such inventory requests, as part of theoverall management and maintenance of inventory system. For example,management module 109 may generate task assignments in response to theoccurrence of a particular event (e.g., in response to a mobile driveunit 114 requesting a space to park), according to a predeterminedschedule (e.g., as part of a daily start-up routine), or at anyappropriate time based on the configuration and characteristics ofinventory system. After generating one or more task assignments,management module 109 transmits the generated task assignments toappropriate components for completion of the corresponding task. Therelevant components then execute their assigned tasks.

With respect to mobile drive units 114 specifically, management module109 may, in particular embodiments, communicate task assignments toselected mobile drive units 114 that identify one or more destinationsfor the selected mobile drive units 114. Management module 109 mayselect a mobile drive unit 114 to assign the relevant task based on thelocation or state of the selected mobile drive unit 114, an indicationthat the selected mobile drive unit 114 has completed apreviously-assigned task, a predetermined schedule, and/or any othersuitable consideration. These destinations may be associated with aninventory request the management module 109 is executing or a managementobjective the management module 109 is attempting to fulfill. Forexample, the task assignment may define the location of a containerholder to be retrieved, an inventory station to be visited, a storagelocation where the mobile drive unit 114 should park until receivinganother task, or a location associated with any other task appropriatebased on the configuration, characteristics, and/or state of inventorysystem, as a whole, or individual components of inventory system. Forexample, in particular embodiments, such decisions may be based on thepopularity of particular inventory items, the staffing of a particularinventory station, the tasks currently assigned to a particular mobiledrive unit 114, and/or any other appropriate considerations.

As part of completing these tasks, mobile drive units 114 may dock withand transport container holders within physical workspace 118. Mobiledrive units 114 may dock with container holders by connecting to,lifting, and/or otherwise interacting with container holders in anyother suitable manner so that, when docked, mobile drive units 114 arecoupled to and/or support container holders and can move containerholders within physical workspace 118. While the description belowfocuses on particular embodiments of mobile drive unit 114 and containerholder that are configured to dock in a particular manner, alternativeembodiments of mobile drive unit 114 and container holder may beconfigured to dock in any manner suitable to allow mobile drive unit 114to move container holder within physical workspace 118.

While the appropriate components of inventory system complete assignedtasks, management module 109 may interact with the relevant componentsto ensure the efficient use of space, equipment, manpower, and otherresources available to inventory system. As one specific example of suchinteraction, management module 109 is responsible, in particularembodiments, for planning the paths mobile drive units 114 take whenmoving within physical workspace 118 and for allocating use of aparticular portion of physical workspace 118 to a particular mobiledrive unit 114 for purposes of completing an assigned task. In suchembodiments, mobile drive units 114 may, in response to being assigned atask, request a path to a particular destination associated with thetask. Moreover, while the description below focuses on one or moreembodiments in which mobile drive unit 114 requests paths frommanagement module 109, mobile drive unit 114 may, in alternativeembodiments, generate its own paths.

Components of inventory system may provide information to managementmodule 109 regarding their current state, other components of inventorysystem with which they are interacting, and/or other conditions relevantto the operation of inventory system. This may allow management module109 to utilize feedback from the relevant components to update algorithmparameters, adjust policies, or otherwise modify its decision-making torespond to changes in operating conditions or the occurrence ofparticular events. At least some of the feedback may be transmitted tothe backend computing device 116 to present to a user interface for theuser 102 and/or update a status of a maintenance task of an activitytemplate defined by the user device 104.

In addition, while management module 109 may be configured to managevarious aspects of the operation of the components of inventory system,in particular embodiments, the components themselves may also beresponsible for decision-making relating to certain aspects of theiroperation, thereby reducing the processing load on management module109.

Thus, based on its knowledge of the location, current state, and/orother characteristics of the various components of inventory system andan awareness of all the tasks currently being completed, managementmodule 109 can generate tasks, allot usage of system resources, andotherwise direct the completion of tasks by the individual components ina manner that optimizes operation from a system-wide perspective.Moreover, by relying on a combination of both centralized, system-widemanagement and localized, component-specific decision-making, particularembodiments of inventory system may be able to support a number oftechniques for efficiently executing various aspects of the operation ofinventory system. As a result, particular embodiments of managementmodule 109 may, by implementing one or more management techniquesdescribed below, enhance the efficiency of inventory system and/orprovide other operational benefits.

FIG. 2 illustrates an example architecture of the backend computingdevice and schedule data store, according to at least one example. Inillustration 200, computing device 210 may correspond with the backendcomputing device 106 illustrated with FIG. 1.

In some aspects, the computing device 210 may also be any type ofcomputing devices such as, but not limited to, a mobile phone, a smartphone, a personal digital assistant (PDA), a laptop computer, a desktopcomputer, a server computer, a thin-client device, a tablet PC, etc.Additionally, it should be noted that in some embodiments, the computingdevice 210 may be executed by one more virtual machines implemented in ahosted computing environment. The hosted computing environment mayinclude one or more rapidly provisioned and released computingresources, which computing resources may include computing, networkingand/or storage devices. A hosted computing environment may also bereferred to as a cloud computing environment. In some examples, thecomputing device 210 may be in communication with one or more userdevices and/or other service providers via a communication network. Thecomputing device 210 may include one or more servers, perhaps arrangedin a cluster, as a server farm, or as individual servers not associatedwith one another. These servers may be configured to implement theanalysis and processing described herein as part of an integrated,distributed computing environment.

In one illustrative configuration, the computing device 210 may includeat least one memory 218 and one or more processing units (orprocessor(s)) 224. The processor(s) 224 may be implemented asappropriate in hardware, computer-executable instructions, firmware, orcombinations thereof. Computer-executable instruction or firmwareimplementations of the processor(s) 224 may include computer-executableor machine-executable instructions written in any suitable programminglanguage to perform the various functions described.

The memory 218 may store program instructions that are loadable andexecutable on the processor(s) 224, as well as data generated during theexecution of these programs. Depending on the configuration and type ofcomputing device 210, the memory 218 may be volatile (such as RAM)and/or non-volatile (such as ROM, flash memory, etc.). The computingdevice 210 may also include additional storage 226, which may includeremovable storage and/or non-removable storage. The additional storage226 may include, but is not limited to, magnetic storage, optical disksand/or tape storage. The disk drives and their associatedcomputer-readable media may provide non-volatile storage ofcomputer-readable instructions, data structures, program modules andother data for the computing devices. In some implementations, thememory 218 may include multiple different types of memory, such as SRAM,DRAM, or ROM.

The memory 218, the additional storage 226, both removable andnon-removable, are examples of computer-readable storage media. Forexample, computer-readable storage media may include volatile ornon-volatile, removable or non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules, or other data. Thememory 218 and the additional storage 226 are examples of computerstorage media. Additional types of computer storage media that may bepresent in the computing device 210 may include, but are not limited to,PRAM, SRAM, DRAM, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, DVD or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computing device 210. Combinations of anyof the above should also be included within the scope ofcomputer-readable media.

Alternatively, computer-readable communication media may includecomputer-readable instructions, program modules, or other datatransmitted within a data signal, such as a carrier wave, or othertransmission. However, as used herein, computer-readable storage mediadoes not include computer-readable communication media.

The computing device 210 may also contain communications connection(s)228 that allow computing device 210 to communicate with a storeddatabase, another computing device or server, user terminals and/orother devices on a communication network. The computing device 210 mayalso include I/O device(s) 230, such as a keyboard, a mouse, a pen, avoice input device, a touch input device, a display, speakers, aprinter, etc.

Turning to the contents of the memory 218 in more detail, the memory 218may include an operating system 232, one or more data stores 234, and/orone or more application programs or services for implementing thefeatures disclosed herein including a template module 236, a thresholdmodule 238, a monitor module 240, a command drive module 242, feedbackmodule 244, and/or a validation module 246. The modules may be softwaremodules, hardware modules, or a combination thereof. If the modules aresoftware modules, the modules will be embodied on a computer readablemedium and processed by a processor in any of computer systems describedherein.

The template module 236 may be configured to validate input received inassociation with an activity template or an input template that helps todefine a maintenance process for a plurality of mobile drive units ofthe physical workspace. For example, in an activity template, theactivities may be limited to pre-defined activities stored in a datastore. The template module 236 may be configured to receive a list ofavailable activities from a data store and present the list of availableactivities to a user interface for selection with the activity template.These may include move, stop, accept software or hardware upgrade,restart, and the like. The template module 236 may confirm that theactivities received from user input correspond with one or morepre-defined activities. In another example, the template module 236 mayconfirm that input received for the input template is accurate. This mayinclude confirming any mobile drive unit information corresponds withavailable mobile drive units in the physical workspace and otherinformation accepted as input for the input template.

The template module 236 may also be configured to receive input for theinput template. For example, unlike the activity template, the inputtemplate may allow free-form input from the user. The input may comprisea firmware update description, a version number of a firmware upgrade, amodel number of new hardware that may be installed with the mobile driveunit, a sensor setting (e.g., new camera setting, etc.), and the like.In some examples, the available input may be identified from a datastore and filtered based at least in part on the selected activity forthe activity template.

The template module 236 may also be configured to store the activitytemplate and the input template as separate executable files. In someexamples, the separation of templates may enable the system to providethese templates to users to alter and select for different uses. Forexample, a particular input may identify a particular subset of mobiledrive units. When the input template is reused, the particular subset ofmobile drive units may perform a different action according to adifferent activity template without the need for selecting the subset ofmobile drive units a second time. In another example, a particularactivity may identify a plurality of steps. When the activity templateis reused, the particular subset of activities may be performed bydifferent mobile drive units or correspond with different firmwareversions that are identified in new input for the reused activitytemplate.

The template module 236 may also be configured to reuse templates. Forexample, an activity may comprise a credential rotation. This mayinclude one or more mobile drive units that are operable according to acredential associated with firmware. The credential may be refreshedaccording to a time period (e.g., every six months). A first subset ofmobile drive units may operate in association with a first credentialand a second subset of mobile drive units may operate in associationwith a second credential. When the first credential is about to expire,the activity template in association with rotating credentials may beactivated to associate the first subset of mobile drive units with athird credential and remove the first credential. In this example, theactivity template may comprise moving the first subset of mobile driveunits to a first location, removing the first credential from the firstsubset of mobile drive units, adding the third credential to the firstsubset of mobile drive units, and moving the first subset of mobiledrive units to a second location. This activity template may beactivated according at the time period (e.g., activate the templateevery six month, automatically, etc.) and the input in association withthis activity template may be updated to identify the new subset ofmobile drive units, which credential to remove, and which new credentialto add.

The threshold module 238 may be configured to alter the actions of oneor more mobile drive units in response to one or more failure rules. Insome examples, the operation of a mobile drive unit (e.g., received in astatus update via the monitoring module 240) may trigger an errornotification that is transmitted from the mobile drive unit to thethreshold module 238. When received, the threshold module 238 mayincrement an error rating in association with the mobile driving inresponse to the status update. The error reading may be compared with acritical threshold or other threshold identifier. When the error readingexceeds the critical threshold, the threshold module 238 may determinean instruction for the mobile drive units in response to the errorstatus.

The threshold module 238 may also be configured to perform a root causedetermination (e.g., based at least in part on the status update, etc.).For example, when a failure rule is activated and/or a criticalthreshold has been met or exceeded, the threshold module 238 maydetermine the cause of the failure. This may identify relevant statusupdates from the mobile device or management module, or the activitythat has completed just prior to the reported failure. In some examples,the threshold module may identify activities that are critical and flagthese activities in the data store to help determine the root cause ofthe failure. As a simple illustration, a firmware update may be acritical activity that a movement of a mobile drive unit may not.

The monitor module 240 may be configured to receive status updates fromone or more mobile drive units during or after completion of one or moreoperations. In some examples, the monitor module 240 may provide thestatus of a mobile drive units in relation to the configurableelectronic instructions from the user. The user may identify one or moresteps of the process that the mobile drive unit has completed based atleast in part on the monitor module display via the user interface.

The command drive module 242 may be configured to determine configurableelectronic instructions of configurable steps for one or more mobiledrive units. The command drive module 242 may identify high levelmovement of the mobile drive unit and the mobile drive unit itself mayidentify an active path to get to the particular location identified bythe command drive module 242.

The command drive module 242 may also, in communication with thethreshold module 238, to determine an auxiliary or post mortem workflowfor a mobile drive unit upon failure of the activity. As described withthe threshold module 238, the system may determine a root cause offailure for the mobile drive unit. In conjunction with a route causedetermination, the command drive module 242 may identify a pattern thatis common with one or more other mobile drive units that have failed andreport the identified pattern as a status update. In some examples, thecommand drive module 242 may instruct the mobile drive unit toautomatically terminate the configurable steps performed by the mobiledrive unit prior to the expected failure. In some examples, theauxiliary workflow may instruct one or more mobile drive units to returnto a location or other activity. In the example where the failure hashappened, the post mortem workflow may instruct the mobile drive unit toidentify itself to other mobile drive units to avoid potentialcollisions or provide a signal to easily identify the mobile drive unitafter the failure.

The command drive module 242 may also, in communication with thethreshold module 238, to determine a cancelation instruction. Forexample, the cancelation instruction may instruct the mobile drive unitto stop any action associated with the first configurable electronicinstruction. The mobile drive unit may abandon any action from the firstconfigurable electronic instruction (e.g., moving to a first location,receiving the firmware or component upgrade, etc.) and revert back tostandard operations after the cancelation instruction is received.

The feedback module 244 may be configured to provide feedback and statusupdates via the user interface. For example, the feedback module 244 mayprovide a list of activities or steps performed by the mobile drive unitat a particular point in time. This may include any of the analysisperformed by the system as well, including root cause determination of afailure for the mobile drive unit, an auxiliary workflow, a post mortemworkflow, a current location of a mobile drive unit, additionalconfigurable steps that will be performed by the mobile drive unit, orother relevant information. The feedback may be received from the mobiledrive units, from the management module, or other computing devicesassociated with the physical workspace.

The feedback module 244 may also be configured to observe activities ofthe mobile drive units prior to transmitting a subsequent instruction tothe mobile drive units (e.g., at a first time, second time, etc.). Forexample, the feedback module 244 may receive one or more status updatesassociated with the first configurable electronic instruction. Thestatus updates may correspond with observed behavior of the mobile driveunits. The first status update at a first time may identify that themobile drive unit is moving to the first location in accordance with thefirst portion of the instructed activity. The second status update at asecond time may identify that the mobile drive unit has started toreceive the firmware upgrade or the new calibration settings, forexample, in accordance with the second portion of the instructedactivity, and so on. In some examples, the status update may identifythat the mobile drive unit is not performing in accordance with theinstructed activity when the instructed activity is supposed to beoccurring. The feedback may be presented to the user (e.g., asillustrated with FIG. 5), stored with the backend computer, or the like.

The feedback module 244 may also be configured to observe activities ofthe mobile drive units for a time range after the configurableelectronic instruction is transmitted to the mobile drive units. Forexample, the observation may begin upon a predetermined time range(e.g., five minutes after completion of the electronic instructions,etc.). The mobile drive units may be presumed to have completed theconfigurable electronic instruction after the predetermined time range.The feedback module 244 may be configured to observe the activities tohelp ensure that the mobile drive units do not lose capabilities (e.g.,can still receive instructions from the management module, can stilldrive to locations for packing and stowing, etc.). When the activitiesare impaired based at least in part on implementing the configurableelectronic instruction, the error rating may be incremented and/orcompared with a critical threshold. In some examples, the feedbackmodule 244, in communication with the threshold module 238, may transmita cancelation instruction or initiate an auxiliary or post mortemworkflow.

The feedback module 244 may also be configured to throttle activities ofthe mobile drive units based at least in part on the feedback. Forexample, the feedback may identify an obstacle detected in the physicalworkspace. The feedback module 244, in communication with the commanddrive module 242, may instruct the mobile drive unit to avoid theobstacle. In another example, the feedback module 244 may identify acluster of mobile drive units in one area (e.g., the maintenanceworkspace to receive a firmware upgrade, etc.). The feedback module 244,in communication with the command drive module 242, may instruct asubset of the mobile drive units to perform activities in a differentlocation that is away from the cluster of mobile drive units performinga similar activity.

The validation module 246 may be configured to receive user input inassociation with the activity template or the input template and confirmthat the input is acceptable. For example, user input corresponding witha particular mobile drive unit may confirm that the mobile drive unit isavailable in the physical workspace. In another example, the user inputcorresponding with particular configuration settings, firmware versionor other information, component upgrade information, or calibrationsettings may confirm that the information received corresponds withexecutables that are available (e.g., firmware version 1.0 is availablebut not firmware version 2.0, etc.).

The schedule service data store 250 may store scheduling activities ofthe mobile drive units. For example, a first mobile drive unit may beinstructed to move to a first location, receive a firmware upgrade, andmoved to a second location. Each of these three activities may be storedin the schedule service data store 250. The plurality of activitiesperformed by the plurality of mobile drive units may be stored in theschedule service data store 250 and accessed to provide status updatesand update user interfaces in response to the current or futureactivities.

FIG. 3 illustrates in greater detail components of an example managementmodule that may be utilized in particular embodiments of the inventorysystem as described herein, in accordance with at least one embodiment.As shown, the example embodiment of a management module 15 includes aresource scheduling module 92, a route planning module 94, a segmentreservation module 96, an inventory module 97, a communication interfacemodule 98, a processor 90, and a memory 91. Management module 15 mayrepresent a single component, multiple components located at a centrallocation within inventory system, or multiple components distributedthroughout inventory system. For example, management module 15 mayrepresent components of one or more mobile drive units 114 that arecapable of communicating information between the mobile drive units 114and coordinating the movement of mobile drive units 114 within aphysical workspace 118. In general, management module 15 may include anyappropriate combination of hardware and/or software suitable to providethe described functionality.

Processor 90 is operable to execute instructions associated with thefunctionality provided by management module 15. Processor 90 maycomprise one or more general purpose computers, dedicatedmicroprocessors, or other processing devices capable of communicatingelectronic information. Examples of processor 90 include one or moreapplication-specific integrated circuits (ASICs), field programmablegate arrays (FPGAs), digital signal processors (DSPs) and any othersuitable specific or general purpose processors.

Memory 91 stores processor instructions, inventory requests, reservationinformation, state information for the various components of inventorysystem and/or any other appropriate values, parameters, or informationutilized by management module 15 during operation. Memory 91 mayrepresent any collection and arrangement of volatile or nonvolatile,local or remote devices suitable for storing data. Examples of memory 91include, but are not limited to, random access memory (RAM) devices,read only memory (ROM) devices, magnetic storage devices, opticalstorage devices or any other suitable data storage devices.

Resource scheduling module 92 processes received inventory requests andgenerates one or more assigned tasks to be completed by the componentsof inventory system. Resource scheduling module 92 may also select oneor more appropriate components for completing the assigned tasks and,using communication interface module 98, communicate the assigned tasksto the relevant components. Additionally, resource scheduling module 92may also be responsible for generating assigned tasks associated withvarious management operations, such as prompting mobile drive units 114to recharge batteries or have batteries replaced, instructing inactivemobile drive units 114 to park in a location outside the anticipatedtraffic flow or a location near the anticipated site of future tasks,and/or directing mobile drive units 114 selected for repair ormaintenance to move towards a designated maintenance station.

Route planning module 94 receives route requests from mobile drive units114. These route requests identify one or more destinations associatedwith a task the requesting mobile drive unit 114 is executing. Inresponse to receiving a route request, route planning module 94generates a path to one or more destinations identified in the routerequest. Route planning module 94 may implement any appropriatealgorithms utilizing any appropriate parameters, factors, and/orconsiderations to determine the appropriate path. After generating anappropriate path, route planning module 94 transmits a route responseidentifying the generated path to the requesting mobile drive unit 114using communication interface module 98.

Segment reservation module 96 receives reservation requests from mobiledrive units 114 attempting to move along paths generated by routeplanning module 94. These reservation requests request the use of aparticular portion of physical workspace 118 (referred to herein as a“segment”) to allow the requesting mobile drive unit 114 to avoidcollisions with other mobile drive units 114 while moving across thereserved segment. In response to received reservation requests, segmentreservation module 96 transmits a reservation response granting ordenying the reservation request to the requesting mobile drive unit 114using the communication interface module 98.

The inventory module 97 maintains information about the location andnumber of inventory items in the inventory system. Information can bemaintained about the number of inventory items in a particular containerholder, and the maintained information can include the location of thoseinventory items in the container holder. The inventory module 97 canalso communicate with the mobile drive units 114, utilizing taskassignments to maintain, replenish or move inventory items within theinventory system. In a particular embodiment, the inventory module 97can coordinate the transfer of containers between container holders andother locations where container can be held. For example, the inventorymodule 97 may be configured to provide human-readable and/ormachine-readable instructions to operators, whether human, automated, orotherwise, identifying containers within container holders that are tobe transferred.

Communication interface module 98 facilitates communication betweenmanagement module 15 and other components of inventory system, includingreservation responses, reservation requests, route requests, routeresponses, and task assignments. These reservation responses,reservation requests, route requests, route responses, and taskassignments may represent communication of any form appropriate based onthe capabilities of management module 15 and may include any suitableinformation. Depending on the configuration of management module 15,communication interface module 98 may be responsible for facilitatingeither or both of wired and wireless communication between managementmodule 15 and the various components of inventory system. In particularembodiments, management module 15 may communicate using communicationprotocols such as 802.11, Bluetooth, or Infrared Data Association (IrDA)standards. Furthermore, management module 15 may, in particularembodiments, represent a portion of mobile drive unit 114 or othercomponents of inventory system. In such embodiments, communicationinterface module 98 may facilitate communication between managementmodule 15 and other parts of the same system component.

In general, resource scheduling module 92, route planning module 94,segment reservation module 96, inventory module 97, and communicationinterface module 98 may each represent any appropriate hardware and/orsoftware suitable to provide the described functionality. In addition,as noted above, management module 15 may, in particular embodiments,represent multiple different discrete components and any or all ofresource scheduling module 92, route planning module 94, segmentreservation module 96, inventory module 97, and communication interfacemodule 98 may represent components physically separate from theremaining elements of management module 15. Moreover, any two or more ofresource scheduling module 92, route planning module 94, segmentreservation module 96, inventory module 97, and communication interfacemodule 98 may share common components. For example, in particularembodiments, resource scheduling module 92, route planning module 94,segment reservation module 96, and inventory module 97 representcomputer processes executing on processor 90 and communication interfacemodule 98 comprises a wireless transmitter, a wireless receiver, and arelated computer process executing on processor 90.

FIGS. 4A and 4B illustrate in greater detail an example mobile driveunit that may be utilized in particular embodiments of the inventorysystem as described herein, in accordance with at least one embodiment.In particular, FIGS. 4A and 4B include a front and side view of anexample mobile drive unit 114. Mobile drive unit 114 includes a dockinghead 110, a drive module 120, a docking actuator 130, and a controlmodule 170. Additionally, mobile drive unit 114 may include one or moresensors configured to detect or determine the location of mobile driveunit 114, container holder, and/or other appropriate elements ofinventory system. In the illustrated embodiment, mobile drive unit 114includes a position sensor 140, a holder sensor 150, an obstacle sensor160, and an identification signal transmitter 162.

Any of these or other components of the mobile drive unit 114 may beidentified in the maintenance activity and/or input template. Forexample, the position sensor 140, holder sensor 150, or obstacle sensor160 may require calibration, or a docking actuator 130 may requirereplacement with a new docking actuator. In a sample illustration, thefirst user input associated with the activity template may identify theparticular sensor and the request for calibration of the sensor. Thesecond user input associated with the input template may identify themobile drive units the comprise the particular sensor and define themaintenance process as calibrating the sensors in these mobile driveunits. In some examples, a status of these components (e.g.,operational, disabled, pending operation, etc.) may be transmitted tothe backend computing device 106 or management module 109, asillustrated in FIG. 1.

Docking head 110, in particular embodiments of mobile drive unit 114,couples mobile drive unit 114 to container holder and/or supportscontainer holder when mobile drive unit 114 is docked to containerholder. Docking head 110 may additionally allow mobile drive unit 114 tomaneuver container holder, such as by lifting container holder,propelling container holder, rotating container holder, and/or movingcontainer holder in any other appropriate manner. Docking head 110 mayalso include any appropriate combination of components, such as ribs,spikes, and/or corrugations, to facilitate such manipulation ofcontainer holder. For example, in particular embodiments, docking head110 may include a high-friction portion that abuts a portion ofcontainer holder while mobile drive unit 114 is docked to containerholder. In such embodiments, frictional forces created between thehigh-friction portion of docking head 110 and a surface of containerholder may induce translational and rotational movement in containerholder when docking head 110 moves and rotates, respectively. As aresult, mobile drive unit 114 may be able to manipulate container holderby moving or rotating docking head 110, either independently or as apart of the movement of mobile drive unit 114 as a whole.

Drive module 120 propels mobile drive unit 114 and, when mobile driveunit 114 and container holder are docked, container holder. Drive module120 may represent any appropriate collection of components operable topropel mobile drive unit 114. For example, in the illustratedembodiment, drive module 120 includes motorized axle 122, a pair ofmotorized wheels 124, and a pair of stabilizing wheels 126. Onemotorized wheel 124 is located at each end of motorized axle 122, andone stabilizing wheel 126 is positioned at each end of mobile drive unit114.

Docking actuator 130 moves docking head 110 towards container holder tofacilitate docking of mobile drive unit 114 and container holder.Docking actuator 130 may also be capable of adjusting the position ororientation of docking head 110 in other suitable manners to facilitatedocking. Docking actuator 130 may include any appropriate components,based on the configuration of mobile drive unit 114 and containerholder, for moving docking head 110 or otherwise adjusting the positionor orientation of docking head 110. For example, in the illustratedembodiment, docking actuator 130 includes a motorized shaft (not shown)attached to the center of docking head 110. The motorized shaft isoperable to lift docking head 110 as appropriate for docking withcontainer holder.

Drive module 120 may be configured to propel mobile drive unit 114 inany appropriate manner. For example, in the illustrated embodiment,motorized wheels 124 are operable to rotate in a first direction topropel mobile drive unit 114 in a forward direction. Motorized wheels124 are also operable to rotate in a second direction to propel mobiledrive unit 114 in a backward direction. In the illustrated embodiment,drive module 120 is also configured to rotate mobile drive unit 114 byrotating motorized wheels 124 in different directions from one anotheror by rotating motorized wheels 124 at different speeds from oneanother.

Position sensor 140 represents one or more sensors, detectors, or othercomponents suitable for determining the location of mobile drive unit114 in any appropriate manner. For example, in particular embodiments,the physical workspace 118 associated with inventory system includes anumber of fiducial marks that mark points on a two-dimensional grid thatcovers all or a portion of physical workspace 118. In such embodiments,position sensor 140 may include a camera and suitable image- and/orvideo-processing components, such as an appropriately-programmed digitalsignal processor, to allow position sensor 140 to detect fiducial markswithin the camera's field of view. Control module 170 may store locationinformation that position sensor 140 updates as position sensor 140detects fiducial marks. As a result, position sensor 140 may utilizefiducial marks to maintain an accurate indication of the location mobiledrive unit 114 and to aid in navigation when moving within physicalworkspace 118.

Holder sensor 150 represents one or more sensors, detectors, or othercomponents suitable for detecting container holder and/or determining,in any appropriate manner, the location of container holder, as anabsolute location or as a position relative to mobile drive unit 114.Holder sensor 150 may be capable of detecting the location of aparticular portion of container holder or container holder as a whole.Mobile drive unit 114 may then use the detected information for dockingwith or otherwise interacting with container holder.

Obstacle sensor 160 represents one or more sensors capable of detectingobjects located in one or more different directions in which mobiledrive unit 114 is capable of moving. Obstacle sensor 160 may utilize anyappropriate components and techniques, including optical, radar, sonar,pressure-sensing and/or other types of detection devices appropriate todetect objects located in the direction of travel of mobile drive unit114. In particular embodiments, obstacle sensor 160 may transmitinformation describing objects it detects to control module 170 to beused by control module 170 to identify obstacles and to take appropriateremedial actions to prevent mobile drive unit 114 from colliding withobstacles and/or other objects.

Obstacle sensor 160 may also detect signals transmitted by other mobiledrive units 114 operating in the vicinity of the illustrated mobiledrive unit 114. For example, in particular embodiments of inventorysystem, one or more mobile drive units 114 may include an identificationsignal transmitter 162 that transmits a drive identification signal. Thedrive identification signal indicates to other mobile drive units 114that the object transmitting the drive identification signal is in facta mobile drive unit. Identification signal transmitter 162 may becapable of transmitting infrared, ultraviolet, audio, visible light,radio, and/or other suitable signals that indicate to recipients thatthe transmitting device is a mobile drive unit 114.

Additionally, in particular embodiments, obstacle sensor 160 may also becapable of detecting state information transmitted by other mobile driveunits 114. For example, in particular embodiments, identification signaltransmitter 162 may be capable of including state information relatingto mobile drive unit 114 in the transmitted identification signal. Thisstate information may include, but is not limited to, the position,velocity, direction, and the braking capabilities of the transmittingmobile drive unit 114. In particular embodiments, mobile drive unit 114may use the state information transmitted by other mobile drive units toavoid collisions when operating in close proximity with those othermobile drive units.

Control module 170 monitors and/or controls operation of drive module120 and docking actuator 130. Control module 170 may also receiveinformation from sensors such as position sensor 140 and holder sensor150 and adjust the operation of drive module 120, docking actuator 130,and/or other components of mobile drive unit 114 based on thisinformation. Additionally, in particular embodiments, mobile drive unit114 may be configured to communicate with a management device ofinventory system and control module 170 may receive commands transmittedto mobile drive unit 114 and communicate information back to themanagement device utilizing appropriate communication components ofmobile drive unit 114. Control module 170 may include any appropriatehardware and/or software suitable to provide the describedfunctionality. In particular embodiments, control module 170 includes ageneral-purpose microprocessor programmed to provide the describedfunctionality. Additionally, control module 170 may include all orportions of docking actuator 130, drive module 120, position sensor 140,and/or holder sensor 150, and/or share components with any of theseelements of mobile drive unit 114.

Moreover, in particular embodiments, control module 170 may includehardware and software located in components that are physically distinctfrom the device that houses drive module 120, docking actuator 130,and/or the other components of mobile drive unit 114 described above.For example, in particular embodiments, each mobile drive unit 114operating in inventory system may be associated with a software process(referred to here as a “drive agent”) operating on a server that is incommunication with the device that houses drive module 120, dockingactuator 130, and other appropriate components of mobile drive unit 114.This drive agent may be responsible for requesting and receiving tasks,requesting and receiving routes, transmitting state informationassociated with mobile drive unit 114, and/or otherwise interacting withmanagement module 15 and other components of inventory system on behalfof the device that physically houses drive module 120, docking actuator130, and the other appropriate components of mobile drive unit 114. As aresult, for the purposes of this description and the claims that follow,the term “mobile drive unit” includes software and/or hardware, such asagent processes, that provides the described functionality on behalf ofmobile drive unit 114 but that may be located in physically distinctdevices from the drive module 120, docking actuator 130, and/or theother components of mobile drive unit 114 described above.

While FIGS. 4A and 4B illustrate a particular embodiment of mobile driveunit 114 containing certain components and configured to operate in aparticular manner, mobile drive unit 114 may represent any appropriatecomponent and/or collection of components configured to transport and/orfacilitate the transport of container holders. As another example,mobile drive unit 114 may represent part of an overhead crane system inwhich one or more crane assemblies are capable of moving within anetwork of wires or rails to a position suitable to dock with aparticular container holder. After docking with container holder, thecrane assembly may then lift container holder and move inventory toanother location for purposes of completing an assigned task.

Furthermore, in particular embodiments, mobile drive unit 114 mayrepresent all or a portion of container holder. Container holder mayinclude motorized wheels or any other components suitable to allowcontainer holder to propel itself. As one specific example, a portion ofcontainer holder may be responsive to magnetic fields. Inventory systemmay be able to generate one or more controlled magnetic fields capableof propelling, maneuvering and/or otherwise controlling the position ofcontainer holder as a result of the responsive portion of containerholder. In such embodiments, mobile drive unit 114 may represent theresponsive portion of container holder and/or the components ofinventory system responsible for generating and controlling thesemagnetic fields. While this description provides several specificexamples, mobile drive unit 114 may, in general, represent anyappropriate component and/or collection of components configured totransport and/or facilitate the transport of container holders.

FIG. 5 illustrates a process flow of user interfaces provided by acomputing device, in accordance with at least one embodiment. Forexample, in illustration 500, the backend computing device 106 maycommunicate with the management module 109 to facilitate communicationwith other components of the inventory system. As a sample illustration,the backend computing device 106 may determine a high level series ofconfigurable steps performed by the mobile drive units and themanagement module 109 may determine the feasibility of particularinstructions with respect to other route requests, reservation requests,task assignments, and the like. Using the new information, the backendcomputing device 106 may populate one or more user interfaces withreal-time information from the physical workspace.

At step 1, a computing device of the system provides a user interfacewith fields for the user to define a new maintenance activity template,input profile, view ongoing maintenance for the mobile drive units, orschedule feature maintenance for the mobile drive units. The user mayselect any of these options, including the option to generate a newmaintenance activity template.

At step 2, the computing device may display a user interface foraccepting the definition and configurable settings of the activitytemplate. The user may define one or more activities for the mobiledrive unit. For example, the activity templates (illustrated as A₁, A₂,. . . A_(N)) may comprise one or more configurable options for each ofthe activity templates (illustrated as C₁, C₂, . . . C_(N)). The servercomputer may also receive a name or other identifier for a plurality ofnew activity templates (or individual activity templates) and store thegrouping in a data store.

In a sample illustration, the first activity may correspond withinstructing the mobile drive unit to drive to a first location, thesecond activity may correspond with instructing the mobile drive unit toreceive a firmware or component upgrade, and the third activity maycorrespond with instructing the mobile drive unit to return to itsoriginal location from the first location. These three activities may beassociated with the new activity template.

At step 3, the computing device may update the user interface to accepta new input profile through an input template. For example, the userinterface may provide the ability to access a previously storedtemplate. Once selected, the user interface may provide a plurality ofradio buttons for receiving input in association with the inputtemplate. They user interface may provide one or more selection rules(illustrated as R₁, R₂, . . . R_(N)) for a particular input (illustratedas I₁, I₂, . . . I_(N)).

In a sample illustration, continuing with the activity templateillustration, the user may access the maintenance activity template thatit created and provide input for the created activity template. Theinput may correspond with particular mobile drive units that willreceive the firmware upgrade according to the activity template or otherinformation. The other information may comprise the version number ofthe firmware upgrade, an executable file associated with the firmwareupgrade, a device that may perform the firmware upgrade, or otherrelevant information. In some examples, the information may bepre-filtered so that the user is only able to select input that ispermissible by the system for the particular mobile drive unit oroperation(s). The server computer may also receive a name or otheridentifier for the new input template and store the new input templatein a data store.

At step 4, the computing device may present the user with a userinterface to select a previously identified activity template. The usermay select a corresponding name of the activity template that wasidentified at step 2.

At step 5, the computing device may allow the user to select apreviously identified input template through the user interface. In someexamples, the user may select a corresponding name of the input templatethat was identified in step 3.

At step 6, the computing device may present the user with a userinterface to initiate the activities associated with the configurableelectronic instruction identified in the activity template and inputtemplate. For example, the user may identify a maximum number of mobiledrive units that may perform the configurable steps in the physicalworkspace or any failure rules that the user would like to add inaddition to any failure rules determined by the computing device. Theuser interface may also prompt the user to initiate the steps performedby the subset of the plurality of mobile drive units at the present timeor at a future time.

The failure rules may be automatically added, sometimes irrespective ofthe input from the user interface. For example, the computing device mayreceive an activity that may correspond with a failure rule by matchingthe activity with a potential failure rule stored in the data store. Thecorrelation between activities and failure rules may be predetermined,so that when the activity is selected by the user, the computing devicemay automatically correlate the failure rule with the activity. In someexamples, the determined failure rule may be transmitted to the mobiledrive unit and a similar process as transmitting the configurableelectronic instruction to perform an activity.

As a sample illustration, the activity may be moving a mobile drive unitand the potential failure may correspond with the mobile drive unit notmoving. The identification of the failure may be determined from thestatus or feedback. The status of the mobile drive unit may identifythat the mobile drive unit is instructed to move, but the mobile driveunit location has remained unchanged in the feedback (e.g., based atleast in part on positioning system data, GPS, or the like). As shown inthis illustration, when the computing device receives an activityassociated with moving the mobile drive unit, for example, the computingdevice may automatically correlate the failure rule associated with notbeing able to move the mobile drive unit.

In some examples, the configurable activities performed by the mobiledrive units may correspond with a time range. For example, the activityand input templates may be identified for the subset of mobile driveunits in association with configurable electronic instructions ofconfigurable steps performed by a subset of mobile drive units. The usermay also identify a first time range for a first configurable electronicinstruction and a second time range for a second configurable electronicinstruction, so that the configurable electronic instructions may beperformed according to these identified time ranges. These time rangesmay correspond with a timing that the mobile drive unit will perform theactions. The system may transmit the configurable electronic instructionso that the mobile drive units are enabled perform these instructionsduring the first and second time ranges, respectively.

In some examples, feedback may alter the time ranges for performingthese activities. As a sample illustration, the feedback may identify amobile drive unit as unable to perform a move operation. In response tothe feedback, the system may adjust the first time range or the secondtime range to delay a start of the activity. In some examples, thesystem may adjust the first time range or the second time range tocorrespond with a different mobile drive unit.

At step 7, the computing device may provide a confirmation network pagethat includes details received from the user interface in associationwith step 6. In some examples, the user interface may provide access todetailed status information of the one or more mobile drive units.

At step 8, the computing device may provide a detailed status update. Insome examples the detailed status update may identify a particularconfigurable step in the identified activity template and presentadditional information associated with that step. This may include aparticular mobile drive unit that has started implementing theconfigurable step, a start or end time of the status of the activity,and other information.

The user interface may also permit a maintenance status lookup via theuser interface. For example, at step 9, a user may determine which ofthe activities have been submitted to mobile drive units in the form ofconfigurable electronic instructions. The user interface may alsoprovide access to activities that are performed in particular areas ofthe physical workspace and/or time ranges when activities will takeplace. In response to the lookup via the user interface, the computingdevice may track these requests in a status list or audit log asillustrated with step 10.

FIG. 6 illustrates an activity template submission workflow, accordingto an embodiment of the disclosure. In illustration 600, the computingdevices may receive the input from the user device as part of theactivity template submission workflow. The computing device maycorrespond with the backend computing device 106 and the managementmodule 109 in FIG. 1, in some examples.

The activity template submission workflow may accept various input. Forexample, the computing device may accept one or more identifiers (e.g.,workflow identifier, zone identifier, etc.), one or more activitytemplate groups that correspond with a particular mobile drive unit anduser input associated with an input template, and/or one or moreactivity templates that have been previously defined by users throughthe user interface. In some examples, the input template may acceptdirect input specifying subset of drives. In some examples, the activitytemplate may accept parameters for each activity in the activitytemplate (e.g., firmware version, etc.).

In some examples, the computing device may bind the input received foran input template to an activity template in the activity templatesubmission workflow process. The computing device may also store statusupdates of the mobile drive units with the system in a data store. Oncethe input is found to the activity template, the computing device maydetermine a configurable electronic instruction of steps to submit tothe mobile drive unit or corresponding management module. In someexamples, the management module may act as a buffer for receivingelectronic instructions for the mobile drive units (e.g., a mobile driveunit scheduling service, KSS, etc.).

In some examples, the activity template submission workflow may enable afirst user input corresponding with an input template to be copied orpropagated to other templates. The computing device may, for example,bind the input to other activities, or may bind the activities to otherinput. In some examples, the activity template submission workflow mayarticulate the relationship between one or more mobile drive units anduser input and/or activities.

The state store may store status information in association with one ormore mobile drive units and activity templates. In some examples, thesystem may generate and store identifiers in association with the statusof the mobile drive units and activities.

FIG. 7 illustrates an activity template update, in accordance with atleast one embodiment. In illustration 700, the computing device mayreceive the input from the user device and look up activity templateinformation in response to the input. The computing devices maycorrespond with the backend computing device 106 and the managementmodule 109 in FIG. 1, in some examples.

The system may access and provide the latest status of the actualexecution of one or more mobile drive units in response to theconfigurable electronic instructions via the user interface. Forexample, the management module may retrieve current status informationvia a fetch update command. The management module may transmit thestatus data of one or more mobile drive units to the computing device.The computing device may correlate the identifier received from themanagement module with additional information corresponding to anidentifier stored with the scheduling service data store. Additionalinformation may be added in association with any additional dataidentified from the scheduling service data store. The information fromthe management module and the additional information may be provided viathe user interface.

FIG. 8 illustrates a sample user interface for scheduling a reoccurringactivity, in accordance with at least one embodiment. For example, thecomputing device may present a list of available activity templates anda list of available input templates via a user interface 800. The usermay select an activity template and corresponding input template. Aselection of the schedule for implementing the activity withcorresponding inputs may also be initiated. For example, the reoccurringactivity may occur every Monday and Thursday of the week, as oneillustration.

FIG. 9 illustrates an illustrative queued drive maintenance workflow, inaccordance with at least one embodiment. A backend computing device mayperform one or more features of illustration 900 for instructing mobiledrive units in association with a maintenance process. The backendcomputing device may implement a loop of processing that may beinitiated and/or repeated as part of the maintenance process workflow.

The process may correspond with a simple workflow service (SWF) activityor may be performed irrespective of SWF. SWF may not be required in someembodiments. In some examples, the SWF may help developers build, run,and scale background jobs that have parallel or sequential steps. SWFmay correspond with a fully-managed state tracker and task coordinatorexecuted at the backend computing device.

At step 902, the system may determine whether the loop is in the firstiteration to help determine information that may be added to a detailedstatus report of operations performed by one or more mobile deviceunits. When the system is implementing the first iteration, the systemmay submit additional templates if necessary. When the system is notimplementing the first iteration, at step 904, a tracking of activitytemplate processes (e.g., a planlet tracker) may be updated and/or addedto the detailed status report. In some examples, the activity templatetracker is a runtime analog of the activity template. In some examples,the system may receive a third input corresponding with a runtimeconfiguration of the electronic instruction.

As a sample illustration, the system may receive a new activity templatewith four activities for the mobile drive unit to perform. The systemmay identify all of the mobile drive units at a particular time todetermine which mobile drive units are available for maintenanceactivities. For each mobile drive unit and activity set, the system maytrack the location and or status of the activity in relation to thedrive.

The system may also identify any errors. The errors may include, forexample, whether any activity templates have timed out 906 or haveexceeded a predetermined amount of time for completing an activity, orwhether it be critical threshold has been breached 908. In someexamples, a maximum number of mobile drive units may be predeterminedand stored with the backend computing device 910. When the maximumnumber of mobile drive units has been reached that correspond with thefailure, the system may identify the failure status. In some examples,the system may wait for a predetermined amount of time before submittingadditional activity instructions (e.g., post-mortem workflow, auxiliaryworkflow, cancelation instruction, etc.).

Upon exit of the loop of activities, the system may determine whetherall mobile drive units are processed. The mobile drive units may not beprocessed when an error has been found in the system may be forced toexit the predetermined activities identified by the activity templatesor error rules. A final status report may be transmitted to identifythis information.

FIG. 10 illustrates an example flow diagram for providing genericmaintenance activity scheduling described herein, according to at leastone example. In some examples, the backend computing device 106 (e.g.,utilizing at least one of the template module 236, the threshold module238, the monitor module 240, the command drive module 242, the feedbackmodule 244, and/or the validation module 246), user device 104,management module 109, or mobile drive unit 114 shown in FIG. 1 mayperform the process 1000 of FIG. 10.

Some or all of the process 1000 (or any other processes describedherein, or variations, and/or combinations thereof) may be performedunder the control of one or more computer systems configured withexecutable instructions and may be implemented as code (e.g., executableinstructions, one or more computer programs, or one or moreapplications) executing collectively on one or more processors, byhardware or combinations thereof. The code may be stored on acomputer-readable storage medium, for example, in the form of a computerprogram comprising a plurality of instructions executable by one or moreprocessors. The computer-readable storage medium may be non-transitory.

The process 1000 may begin at 1002 by receiving a first input associatedwith an activity template. The activity template may correspond with aconfigurable step or steps performed by the plurality of mobile to driveunits of a physical workspace.

In some examples, the computing device may present a user interface thatcomprises a plurality of fields for accepting user input prior toreceiving the input. For example, the computing device may present auser interface that comprises a plurality of fields. At least one fieldmay be associated with user input for defining a maintenance process forthe plurality of mobile drive units of a physical workspace. Themaintenance process may be defined through a configuration of anactivity template and an input template.

In some examples, the computing device may correlate failure rules withthe activity template based at least in part on the first input. Forexample, the first input may comprise a particular step that maycorrespond with a potential for failure (e.g., the drive may not be ableto enter a particular physical location, the drive may not be accessibleor operable, etc.). The computing device may correlate one or moreadditional steps with the activity template that may programmaticallycheck for the potential of failure associated with the activity. In someexamples, the correlation of failure rules may be automatic and withoutadditional instruction from the user device.

At 1004, the computing system may receive a second input associated withinput template. The input template may correspond to the activitytemplate. The input template may identify information associated withone or more steps of the activity including, for example, a selection ofa subset of the plurality of mobile drive units.

At 1006, the computing system may determine a first configurableelectronic instruction of configurable steps based at least in part onthe first input and/or the second input. In some examples, theconfigurable electronic instruction may correspond with the identifiedsubset of the plurality of mobile drive units.

At 1008, the computing system may transmit the configurable electronicinstruction to the mobile drive units. In some examples, the computingdevice may include the failure rules corresponding with the activitytemplate with the transmission of the configurable electronicinstruction.

In some examples, the computing device may reuse the templates inassociation with new input. For example, the computing device mayreceive third input associated with an input template. The third inputmay correspond with a second configurable electronic instruction of theconfigurable steps performed by the subset of the plurality of mobiledrive units. The computing device may transmit the second configurableelectronic instruction with the original failure rules to the mobiledrive units. The same failure rules may be transmitted because theactivity template may be reused with a new input template in thisexample.

FIG. 11 illustrates aspects of an example environment 1200 forimplementing aspects in accordance with various embodiments. As will beappreciated, although a Web-based environment is used for purposes ofexplanation, different environments may be used, as appropriate, toimplement various embodiments. The environment includes an electronicclient device 1102, which can include any appropriate device operable tosend and receive requests, messages, or information over an appropriatenetwork 1104 and convey information back to a user of the device.Examples of such client devices include personal computers, cell phones,handheld messaging devices, laptop computers, set-top boxes, personaldata assistants, electronic book readers, and the like. The network caninclude any appropriate network, including an intranet, the Internet, acellular network, a local area network, or any other such network orcombination thereof. Components used for such a system can depend atleast in part upon the type of network and/or environment selected.Protocols and components for communicating via such a network are wellknown and will not be discussed herein in detail. Communication over thenetwork can be enabled by wired or wireless connections and combinationsthereof. In this example, the network includes the Internet, as theenvironment includes a Web server 1106 for receiving requests andserving content in response thereto, although for other networks analternative device serving a similar purpose could be used as would beapparent to one of ordinary skill in the art.

The illustrative environment includes at least one application server1108 and a data store 1110. It should be understood that there can beseveral application servers, layers, or other elements, processes, orcomponents, which may be chained or otherwise configured, which caninteract to perform tasks such as obtaining data from an appropriatedata store. As used herein the term “data store” refers to any device orcombination of devices capable of storing, accessing, and retrievingdata, which may include any combination and number of data servers,databases, data storage devices, and data storage media, in anystandard, distributed, or clustered environment. The application servercan include any appropriate hardware and software for integrating withthe data store as needed to execute aspects of one or more applicationsfor the client device, handling a majority of the data access andbusiness logic for an application. The application server providesaccess control services in cooperation with the data store and is ableto generate content such as text, graphics, audio, and/or video to betransferred to the user, which may be served to the user by the Webserver in the form of HyperText Markup Language (“HTML”), ExtensibleMarkup Language (“XML”), or another appropriate structured language inthis example. The handling of all requests and responses, as well as thedelivery of content between the client device 1102 and the applicationserver 1108, can be handled by the Web server. It should be understoodthat the Web and application servers are not required and are merelyexample components, as structured code discussed herein can be executedon any appropriate device or host machine as discussed elsewhere herein.

The data store 1110 can include several separate data tables, databasesor other data storage mechanisms and media for storing data relating toa particular aspect. For example, the data store illustrated includesmechanisms for storing production data 1112 and user information 1116,which can be used to serve content for the production side. The datastore also is shown to include a mechanism for storing log data 1114,which can be used for reporting, analysis, or other such purposes. Itshould be understood that there can be many other aspects that may needto be stored in the data store, such as for page image information andto access right information, which can be stored in any of the abovelisted mechanisms as appropriate or in additional mechanisms in the datastore 1110. The data store 1110 is operable, through logic associatedtherewith, to receive instructions from the application server 1108 andobtain, update or otherwise process data in response thereto. In oneexample, a user might submit a search request for a certain type ofitem. In this case, the data store might access the user information toverify the identity of the user and can access the catalog detailinformation to obtain information about items of that type. Theinformation then can be returned to the user, such as in a resultslisting on a Web page that the user is able to view via a browser on theuser device 1102. Information for a particular item of interest can beviewed in a dedicated page or window of the browser.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include a computer-readablestorage medium (e.g., a hard disk, random access memory, read onlymemory, etc.) storing instructions that, when executed by a processor ofthe server, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein.

The environment in one embodiment is a distributed computing environmentutilizing several computer systems and components that areinterconnected via communication links, using one or more computernetworks or direct connections. However, it will be appreciated by thoseof ordinary skill in the art that such a system could operate equallywell in a system having fewer or a greater number of components than areillustrated in FIG. 11. Thus, the depiction of the system 1100 in FIG.11 should be taken as being illustrative in nature and not limiting tothe scope of the disclosure.

The various embodiments further can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of general purpose personal computers, such asdesktop or laptop computers running a standard operating system, as wellas cellular, wireless, and handheld devices running mobile software andcapable of supporting a number of networking and messaging protocols.Such a system also can include a number of workstations running any of avariety of commercially-available operating systems and other knownapplications for purposes such as development and database management.These devices also can include other electronic devices, such as dummyterminals, thin-clients, gaming systems, and other devices capable ofcommunicating via a network.

Most embodiments utilize at least one network that would be familiar tothose skilled in the art for supporting communications using any of avariety of commercially-available protocols, such as TransmissionControl Protocol/Internet Protocol (“TCP/IP”), Open SystemInterconnection (“OSI”), File Transfer Protocol (“FTP”), Universal Plugand Play (“UpnP”), Network File System (“NFS”), Common Internet FileSystem (“CIFS”), and AppleTalk®. The network can be, for example, alocal area network, a wide-area network, a virtual private network, theInternet, an intranet, an extranet, a public switched telephone network,an infrared network, a wireless network, and any combination thereof.

In embodiments utilizing a Web server, the Web server can run any of avariety of server or mid-tier applications, including Hypertext TransferProtocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGP”)servers, data servers, Java servers, and business application servers.The server(s) also may be capable of executing programs or scripts inresponse to requests from user devices, such as by executing one or moreWeb applications that may be implemented as one or more scripts orprograms written in any programming language, such as Java®, C, C #, orC++, or any scripting language, such as Perl, Python, or TCL, as well ascombinations thereof. The server(s) may also include database servers,including without limitation those commercially available from Oracle®,Microsoft®, Sybase®, and IBM®.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers, or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (“CPU”), at least oneinput device (e.g., a mouse, keyboard, controller, touch screen, orkeypad), and at least one output device (e.g., a display device,printer, or speaker). Such a system may also include one or more storagedevices, such as disk drives, optical storage devices, and solid-statestorage devices such as random access memory (“RAM”) or read-only memory(“ROM”), as well as removable media devices, memory cards, flash cards,etc.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired)), an infrared communication device, etc.), and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed, and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting, and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services, or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor Web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets), or both. Further, connection to other computing devicessuch as network input/output devices may be employed.

Storage media computer readable media for containing code, or portionsof code, can include any appropriate media known or used in the art,including storage media and communication media, such as but not limitedto volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules, or other data, including RAM, ROM, ElectricallyErasable Programmable Read-Only Memory (“EEPROM”), flash memory or othermemory technology, Compact Disc Read-Only Memory (“CD-ROM”), digitalversatile disk (DVD), or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage, or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by a system device. Based on the disclosureand teachings provided herein, a person of ordinary skill in the artwill appreciate other ways and/or methods to implement the variousembodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the disclosure asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit thedisclosure to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructions,and equivalents falling within the spirit and scope of the disclosure,as defined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected” is to be construed as partly or wholly contained within,attached to, or joined together, even if there is something intervening.Recitation of ranges of values herein are merely intended to serve as ashorthand method of referring individually to each separate valuefalling within the range, unless otherwise indicated herein and eachseparate value is incorporated into the specification as if it wereindividually recited herein. All methods described herein can beperformed in any suitable order unless otherwise indicated herein orotherwise clearly contradicted by context. The use of any and allexamples, or exemplary language (e.g., “such as”) provided herein, isintended merely to better illuminate embodiments of the disclosure anddoes not pose a limitation on the scope of the disclosure unlessotherwise claimed. No language in the specification should be construedas indicating any non-claimed element as essential to the practice ofthe disclosure.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is intended to be understoodwithin the context as used in general to present that an item, term,etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y,and/or Z). Thus, such disjunctive language is not generally intended to,and should not, imply that certain embodiments require at least one ofX, at least one of Y, or at least one of Z to each be present.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the disclosure.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate and the inventors intend for the disclosure to be practicedotherwise than as specifically described herein. Accordingly, thisdisclosure includes all modifications and equivalents of the subjectmatter recited in the claims appended hereto as permitted by applicablelaw. Moreover, any combination of the above-described elements in allpossible variations thereof is encompassed by the disclosure unlessotherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications, andpatents, cited herein are hereby incorporated by reference to the sameextent as if each reference were individually and specifically indicatedto be incorporated by reference and were set forth in its entiretyherein.

What is claimed is:
 1. A computer-implemented method, comprising:presenting, by a computing device, a user interface that comprises aplurality of fields associated with user input about a maintenanceprocess for a plurality of mobile drive units of a physical workspace,the maintenance process to be defined through a configuration of anactivity template and an input template that are stored separately, theactivity template comprising a maintenance activity, and the inputtemplate comprising a configuration for the maintenance activity;receiving, by the computing device based at least in part on a firstfield of the plurality of fields of the user interface, first user inputto the activity template, the activity template corresponding withconfigurable steps supported by the plurality of mobile drive units ofthe physical workspace, the first user input indicating the maintenanceactivity that corresponds to at least one of the configurable steps;automatically correlating, by the computing device, failure rules withthe activity template based at least in part on the first user input;receiving, by the computing device based at least in part on a secondfield of the plurality of fields of the user interface, second userinput to the input template, the input template corresponding to theactivity template, and the second user input comprising a selection of asubset of the plurality of mobile drive units and indicating theconfiguration of the maintenance activity for the subset of theplurality of mobile drive units; determining, by the computing device, afirst configurable electronic instruction of the configurable stepsbased at least in part on correspondence between the first user inputand the second user input and the activity template; and transmitting,by the computing device, the first configurable electronic instructionand the failure rules to the subset of the plurality of mobile driveunits.
 2. The computer-implemented method of claim 1, furthercomprising: receiving, by the computing device, third user inputassociated with the input template, the third user input correspondingwith a second configurable electronic instruction of the configurablesteps; and transmitting, by the computing device, the secondconfigurable electronic instruction and the failure rules to the subsetof the plurality of mobile drive units, the failure rules correspondingwith the activity template based at least in part on the first userinput.
 3. The computer-implemented method of claim 1, whereintransmitting the first configurable electronic instruction comprises:instructing the subset of the plurality of mobile drive units to move toa first location; enabling acceptance of a component upgrade; andfurther instructing the subset of the plurality of mobile drive unitsaway from the first location.
 4. The computer-implemented method ofclaim 1, wherein receiving the second user input comprises: receivingthe selection of the subset of the plurality of mobile drive units as afirst selection from multiple available selections defined by the inputtemplate, wherein the multiple available selections comprise a secondselection about at least one of a firmware version or sensor calibrationsettings as the configuration of the maintenance activity.
 5. Acomputing device, comprising: a memory configured to storecomputer-executable instructions; and a processor in communication withthe memory configured to execute the computer-executable instructions toat least: present a user interface that comprises at least one fieldabout a maintenance process for a plurality of mobile drive units of aphysical workspace, the maintenance process defined through aconfiguration of an activity template and an input template that arestored separately, the activity template comprising an activity, and theinput template comprising a configuration for the activity; receive,based at least in part on the user interface, first user input to theactivity template, the activity template corresponding with configurablesteps performed by the plurality of mobile drive units of the physicalworkspace, the first user input indicating the activity that correspondsto at least one of the configurable steps; receive, based at least inpart on the user interface, second user input to the input template, theinput template corresponding to the activity template, and the seconduser input comprising a selection of a subset of the plurality of mobiledrive units and indicating the configuration of the activity for thesubset of the plurality of mobile drive units; determine a firstconfigurable electronic instruction of the configurable steps performedby the subset of the plurality of mobile drive units, the firstconfigurable electronic instruction determined based at least in part oncorrespondence with the first user input and the second user input; andtransmit the first configurable electronic instruction to the subset ofthe plurality of mobile drive units.
 6. The computing device of claim 5,wherein the processor is configured to execute furthercomputer-executable instructions to at least: automatically correlatefailure rules with the activity template based at least in part on thefirst user input; and transmit the failure rules to the subset of theplurality of mobile drive units.
 7. The computing device of claim 5,wherein the processor is configured to execute furthercomputer-executable instructions to at least: receive a status updateassociated with the first configurable electronic instruction of theconfigurable steps performed by the subset of the plurality of mobiledrive units.
 8. The computing device of claim 7, wherein the statusupdate initiates a root cause determination process.
 9. The computingdevice of claim 7, wherein the processor is configured to executefurther computer-executable instructions to at least: upon receiving thestatus update, increment an error rating.
 10. The computing device ofclaim 7, wherein the processor is configured to execute furthercomputer-executable instructions to at least: upon receiving the statusupdate, determine an error rating of a step performed by the subset ofthe plurality of mobile drive units; compare the error rating with acritical threshold; and transmit a cancelation instruction to the subsetof the plurality of mobile drive units when the error rating exceeds thecritical threshold.
 11. The computing device of claim 10, wherein theprocessor is configured to execute further computer-executableinstructions to at least: when the error rating exceeds the criticalthreshold, initiate a post-mortem workflow.
 12. One or morenon-transitory computer-readable storage media collectively storingcomputer-executable instructions that, when executed by one or morecomputer systems, configure the one or more computer systems tocollectively perform operations comprising: receiving a definition of amaintenance process for a plurality of mobile drive units of a physicalworkspace, the maintenance process defined through a configuration of anactivity template and an input template that are stored separately, theactivity template comprising a maintenance activity, and the inputtemplate comprising a configuration for the maintenance activity;receiving first user input to the activity template, the activitytemplate corresponding with configurable steps performed by theplurality of mobile drive units of the physical workspace, the firstuser input indicating the maintenance activity that corresponds to atleast one of the configurable steps; receiving second user input to theinput template, the input template corresponding to the activitytemplate, and the second user input comprising a selection of a subsetof the plurality of mobile drive units and indicating the configurationof the maintenance activity for the subset of the plurality of mobiledrive units; determining a first configurable electronic instruction ofthe configurable steps performed by the subset of the plurality ofmobile drive units, the first configurable electronic instructiondetermined based at least in part on correspondence with first userinput and the second user input; and transmitting the first configurableelectronic instruction to the subset of the plurality of mobile driveunits.
 13. The one or more non-transitory computer-readable storagemedia of claim 12, wherein the plurality of mobile drive units areoperable independently from the first user input and the second userinput.
 14. The one or more non-transitory computer-readable storagemedia of claim 12, the operations further comprising: transmitting astatus of operation to a user interface; and presenting the status ofoperation on the user interface.
 15. The one or more non-transitorycomputer-readable storage media of claim 14, wherein presenting thestatus comprises identifying completed activities associated with theactivity template.
 16. The one or more non-transitory computer-readablestorage media of claim 12, wherein an activity identified in theactivity template is a credential rotation.
 17. The one or morenon-transitory computer-readable storage media of claim 12, theoperations further comprising: determining a second configurableelectronic instruction of the configurable steps performed by the subsetof the plurality of mobile drive units; determining a first time rangefor the first configurable electronic instruction and a second timerange for the second configurable electronic instruction; andtransmitting the second configurable electronic instruction, wherein themobile drive units are able to perform the first and second configurableelectronic instructions at the first and second time ranges,respectively.
 18. The one or more non-transitory computer-readablestorage media of claim 17, the operations further comprising: receivingfeedback for a status of the maintenance activity; and adjusting thefirst time range or the second time range based at least in part on thefeedback.
 19. The one or more non-transitory computer-readable storagemedia of claim 12, the operations further comprising: upon transmittingthe first configurable electronic instruction to the subset of theplurality of mobile drive units, receiving data indicating actionsperformed by the subset of the plurality of mobile drive units for apredetermined period of time after an execution of the firstconfigurable electronic instruction on the subset of the plurality ofmobile drive units; determining a status update based at least in parton a subsequent action.
 20. The one or more non-transitorycomputer-readable storage media of claim 12, the operations furthercomprising: receiving, at a first time from a first subset of theplurality of mobile drive units, a first status of an execution of thefirst configurable electronic instruction; and receiving, at a secondtime from a second subset of the plurality of mobile drive units, asecond status of the execution of the first configurable electronicinstruction.